Frontend Micro-Frontend: Овладяване на Module Federation архитектурата

В днешния бързо развиващ се пейзаж на уеб разработката, изграждането и поддържането на големи frontend приложения може да стане все по-сложно. Традиционните монолитни архитектури често водят до предизвикателства като надуване на кода, бавно време за изграждане и трудности при независими внедрявания. Micro-frontends предлагат решение, като разделят frontend на по-малки, по-управляеми части. Тази статия се задълбочава в Module Federation, мощна техника за внедряване на micro-frontends, изследвайки нейните ползи, архитектура и практически стратегии за изпълнение.

Какво представляват Micro-Frontends?

Micro-frontends са архитектурен стил, при който frontend приложението е разложено на по-малки, независими и внедряващи се единици. Всеки micro-frontend обикновено се притежава от отделен екип, което позволява по-голяма автономия и по-бързи цикли на разработка. Този подход отразява архитектурата на микроуслугите, която обикновено се използва на backend.

Ключовите характеристики на micro-frontends включват:

• Независимо внедряване: Всеки micro-frontend може да бъде внедрен независимо, без да засяга други части на приложението.
• Екипна автономия: Различни екипи могат да притежават и разработват различни micro-frontends, използвайки предпочитаните от тях технологии и работни процеси.
• Технологично разнообразие: Micro-frontends могат да бъдат изградени с помощта на различни рамки и библиотеки, което позволява на екипите да изберат най-добрите инструменти за работата.
• Изолация: Micro-frontends трябва да бъдат изолирани един от друг, за да се предотвратят каскадни повреди и да се осигури стабилност.

Защо да използвате Micro-Frontends?

Приемането на micro-frontend архитектура предлага няколко значителни предимства, особено за големи и сложни приложения:

• Подобрена мащабируемост: Разделянето на frontend на по-малки единици улеснява мащабирането на приложението, когато е необходимо.
• По-бързи цикли на разработка: Независимите екипи могат да работят паралелно, което води до по-бързи цикли на разработка и пускане.
• Повишена екипна автономия: Екипите имат повече контрол върху своя код и могат да вземат решения самостоятелно.
• По-лесна поддръжка: По-малките кодови бази са по-лесни за поддръжка и отстраняване на грешки.
• Технологично агностични: Екипите могат да изберат най-добрите технологии за своите специфични нужди, което позволява иновации и експериментиране.
• Намален риск: Внедряванията са по-малки и по-чести, намалявайки риска от широкомащабни повреди.

Въведение в Module Federation

Module Federation е функция, въведена в Webpack 5, която позволява на JavaScript приложенията динамично да зареждат код от други приложения по време на изпълнение. Това дава възможност за създаване на наистина независими и компонуеми micro-frontends. Вместо да изгражда всичко в един пакет, Module Federation позволява на различни приложения да споделят и консумират модулите си, сякаш са локални зависимости.

За разлика от традиционните подходи към micro-frontends, които разчитат на iframes или уеб компоненти, Module Federation предоставя по-плавно и интегрирано изживяване за потребителя. Тя избягва режийните разходи за производителност и сложността, свързани с тези други техники.

Как работи Module Federation

Module Federation работи на концепцията за "излагане" и "консумиране" на модули. Едно приложение ("хост" или "контейнер") може да изложи модули, докато други приложения ("remote") могат да консумират тези изложени модули. Ето разбивка на процеса:

1. Излагане на модули: A micro-frontend, конфигуриран като "remote" приложение в Webpack, излага определени модули (компоненти, функции, помощни програми) чрез конфигурационен файл. Тази конфигурация определя модулите, които трябва да бъдат споделени, и съответните им входни точки.
2. Консумиране на модули: Друг micro-frontend, конфигуриран като "хост" или "контейнер" приложение, декларира remote приложението като зависимост. Той определя URL адреса, където може да бъде намерен манифестът за module federation на remote (малък JSON файл, описващ изложените модули).
3. Разрешаване по време на изпълнение: Когато хост приложението трябва да използва модул от remote приложението, то динамично извлича манифеста за module federation на remote. След това Webpack разрешава зависимостта на модула и зарежда необходимия код от remote приложението по време на изпълнение.
4. Споделяне на код: Module Federation също така позволява споделяне на код между хост и remote приложенията. Ако и двете приложения използват една и съща версия на споделена зависимост (напр. React, lodash), кодът ще бъде споделен, избягвайки дублиране и намалявайки размерите на пакета.

Настройка на Module Federation: Практически пример

Нека илюстрираме Module Federation с прост пример, включващ два micro-frontends: "Каталог на продукти" и "Количка за пазаруване". Каталогът на продукти ще изложи компонент за списък с продукти, който количката за пазаруване ще използва за показване на свързани продукти.

Структура на проекта

  
  micro-frontend-example/
    product-catalog/
      src/
        components/
          ProductList.jsx
        index.js
        webpack.config.js
    shopping-cart/
      src/
        components/
          RelatedProducts.jsx
        index.js
        webpack.config.js
  

Каталог на продукти (Remote)

webpack.config.js

  
  const { ModuleFederationPlugin } = require('webpack').container;
  const path = require('path');

  module.exports = {
    // ... other webpack configurations
    plugins: [
      new ModuleFederationPlugin({
        name: 'product_catalog',
        filename: 'remoteEntry.js',
        exposes: {
          './ProductList': './src/components/ProductList',
        },
        shared: {
          react: { singleton: true, eager: true, requiredVersion: '^17.0.0' },
          'react-dom': { singleton: true, eager: true, requiredVersion: '^17.0.0' },
        },
      }),
    ],
  };
  

Обяснение:

• name: Уникалното име на remote приложението.
• filename: Името на файла с входната точка, който ще бъде изложен. Този файл съдържа манифеста за module federation.
• exposes: Определя кои модули ще бъдат изложени от това приложение. В този случай излагаме компонента `ProductList` от `src/components/ProductList.jsx` под името `./ProductList`.
• shared: Определя зависимостите, които трябва да бъдат споделени между хост и remote приложенията. Това е от решаващо значение за избягване на дублиран код и осигуряване на съвместимост. `singleton: true` гарантира, че се зарежда само един екземпляр на споделената зависимост. `eager: true` зарежда споделената зависимост първоначално, което може да подобри производителността. `requiredVersion` определя приемливия диапазон на версии за споделената зависимост.

src/components/ProductList.jsx

  
  import React from 'react';

  const ProductList = ({ products }) => (
    

      {products.map((product) => (
        
{product.name} - ${product.price}
      ))}
    
  );

  export default ProductList;
  

Количка за пазаруване (Host)

webpack.config.js

  
  const { ModuleFederationPlugin } = require('webpack').container;
  const path = require('path');

  module.exports = {
    // ... other webpack configurations
    plugins: [
      new ModuleFederationPlugin({
        name: 'shopping_cart',
        remotes: {
          product_catalog: 'product_catalog@http://localhost:3001/remoteEntry.js',
        },
        shared: {
          react: { singleton: true, eager: true, requiredVersion: '^17.0.0' },
          'react-dom': { singleton: true, eager: true, requiredVersion: '^17.0.0' },
        },
      }),
    ],
  };
  

Обяснение:

• name: Уникалното име на хост приложението.
• remotes: Определя remote приложенията, от които това приложение ще консумира модули. В този случай декларираме remote с име `product_catalog` и определяме URL адреса, където може да бъде намерен неговият файл `remoteEntry.js`. Форматът е `remoteName: 'remoteName@remoteEntryUrl'`.
• shared: Подобно на remote приложението, хост приложението също дефинира своите споделени зависимости. Това гарантира, че хост и remote приложенията използват съвместими версии на споделените библиотеки.

src/components/RelatedProducts.jsx

  
  import React, { useEffect, useState } from 'react';
  import ProductList from 'product_catalog/ProductList';

  const RelatedProducts = () => {
    const [products, setProducts] = useState([]);

    useEffect(() => {
      // Fetch related products data (e.g., from an API)
      const fetchProducts = async () => {
        // Replace with your actual API endpoint
        const response = await fetch('https://fakestoreapi.com/products?limit=3');
        const data = await response.json();
        setProducts(data);
      };

      fetchProducts();
    }, []);

    return (
      

        
Свързани продукти
        {products.length > 0 ?  : 
Зареждане...
}
      
    );
  };

  export default RelatedProducts;
  

Обяснение:

• import ProductList from 'product_catalog/ProductList'; Този ред импортира компонента `ProductList` от remote `product_catalog`. Синтаксисът `remoteName/moduleName` казва на Webpack да извлече модула от посоченото remote приложение.
• След това компонентът използва импортирания компонент `ProductList` за показване на свързани продукти.

Изпълнение на примера

1. Стартирайте приложенията Каталог на продукти и Количка за пазаруване, като използвате съответните им сървъри за разработка (напр. `npm start`). Уверете се, че работят на различни портове (напр. Каталог на продукти на порт 3001 и Количка за пазаруване на порт 3000).
2. Отидете до приложението Количка за пазаруване във вашия браузър.
3. Трябва да видите секцията Свързани продукти, която се изобразява от компонента `ProductList` от приложението Каталог на продукти.

Разширени концепции за Module Federation

Освен основната настройка, Module Federation предлага няколко разширени функции, които могат да подобрят вашата micro-frontend архитектура:

Споделяне на код и управление на версиите

Както е показано в примера, Module Federation позволява споделяне на код между хост и remote приложенията. Това се постига чрез опцията `shared` за конфигурация в Webpack. Чрез определяне на споделени зависимости, можете да избегнете дублиран код и да намалите размерите на пакета. Правилното управление на версиите на споделените зависимости е от решаващо значение за осигуряване на съвместимост и предотвратяване на конфликти. Semantic versioning (SemVer) е широко използван стандарт за управление на версиите на софтуера, което ви позволява да дефинирате съвместими диапазони на версии (напр. `^17.0.0` позволява всяка версия, по-голяма или равна на 17.0.0, но по-малка от 18.0.0).

Динамични remotes

В предишния пример URL адресът на remote беше кодиран в файла `webpack.config.js`. Въпреки това, в много реални сценарии може да се наложи динамично да определите URL адреса на remote по време на изпълнение. Това може да се постигне с помощта на конфигурация на remote, базирана на promise:

  
  // webpack.config.js
  remotes: {
    product_catalog: new Promise(resolve => {
      // Fetch the remote URL from a configuration file or API
      fetch('/config.json')
        .then(response => response.json())
        .then(config => {
          const remoteUrl = config.productCatalogUrl;
          resolve(`product_catalog@${remoteUrl}/remoteEntry.js`);
        });
    }),
  },
  

Това ви позволява да конфигурирате URL адреса на remote въз основа на средата (напр. разработка, подготвителен етап, производство) или други фактори.

Асинхронно зареждане на модули

Module Federation поддържа асинхронно зареждане на модули, което ви позволява да зареждате модули при поискване. Това може да подобри първоначалното време за зареждане на вашето приложение, като отложите зареждането на некритични модули.

  
  // RelatedProducts.jsx
  import React, { Suspense, lazy } from 'react';

  const ProductList = lazy(() => import('product_catalog/ProductList'));

  const RelatedProducts = () => {
    return (
      

        
Свързани продукти
        Зареждане...
}>
          
        
      
    );
  };
  

Използвайки `React.lazy` и `Suspense`, можете асинхронно да заредите компонента `ProductList` от remote приложението. Компонентът `Suspense` предоставя резервен UI (напр. индикатор за зареждане), докато модулът се зарежда.

Федеративни стилове и активи

Module Federation може да се използва и за споделяне на стилове и активи между micro-frontends. Това може да помогне за поддържане на последователен външен вид на вашето приложение.

За да споделяте стилове, можете да изложите CSS модули или стилизирани компоненти от remote приложение. За да споделяте активи (напр. изображения, шрифтове), можете да конфигурирате Webpack да копира активите в споделено местоположение и след това да ги препращате от хост приложението.

Най-добри практики за Module Federation

При внедряване на Module Federation е важно да следвате най-добрите практики, за да осигурите успешна и поддържаема архитектура:

• Дефинирайте ясни граници: Ясно дефинирайте границите между micro-frontends, за да избегнете тясна връзка и да осигурите независимо внедряване.
• Създайте комуникационни протоколи: Дефинирайте ясни комуникационни протоколи между micro-frontends. Помислете за използване на шини за събития, библиотеки за споделено управление на състоянията или персонализирани API.
• Управлявайте внимателно споделените зависимости: Внимателно управлявайте споделените зависимости, за да избегнете конфликти на версии и да осигурите съвместимост. Използвайте семантично управление на версиите и помислете за използване на инструмент за управление на зависимости като npm или yarn.
• Приложете стабилно обработване на грешки: Приложете стабилно обработване на грешки, за да предотвратите каскадни повреди и да осигурите стабилността на вашето приложение.
• Наблюдавайте производителността: Наблюдавайте производителността на вашите micro-frontends, за да идентифицирате тесни места и да оптимизирате производителността.
• Автоматизирайте внедряванията: Автоматизирайте процеса на внедряване, за да осигурите последователни и надеждни внедрявания.
• Използвайте последователен стил на кодиране: Наложете последователен стил на кодиране във всички micro-frontends, за да подобрите четливостта и поддръжката. Инструменти като ESLint и Prettier могат да помогнат с това.
• Документирайте вашата архитектура: Документирайте вашата micro-frontend архитектура, за да гарантирате, че всички членове на екипа разбират системата и как работи.

Module Federation срещу други подходи за Micro-Frontend

Докато Module Federation е мощна техника за внедряване на micro-frontends, тя не е единственият подход. Други популярни методи включват:

• Iframes: Iframes осигуряват силна изолация между micro-frontends, но може да е трудно да се интегрират безпроблемно и могат да имат режийни разходи за производителност.
• Уеб компоненти: Уеб компонентите ви позволяват да създавате елементи на UI, които могат да се използват повторно в различни micro-frontends. Те обаче могат да бъдат по-сложни за внедряване от Module Federation.
• Интеграция по време на изграждане: Този подход включва изграждане на всички micro-frontends в едно приложение по време на изграждане. Въпреки че може да опрости внедряването, той намалява екипната автономия и увеличава риска от конфликти.
• Single-SPA: Single-SPA е рамка, която ви позволява да комбинирате множество едностранични приложения в едно приложение. Той предоставя по-гъвкав подход от интеграцията по време на изграждане, но може да бъде по-сложен за настройка.

Изборът на подхода, който да използвате, зависи от специфичните изисквания на вашето приложение и размера и структурата на вашия екип. Module Federation предлага добър баланс между гъвкавост, производителност и лекота на използване, което го прави популярен избор за много проекти.

Реални примери за Module Federation

Докато конкретните реализации на компаниите често са поверителни, общите принципи на Module Federation се прилагат в различни индустрии и сценарии. Ето някои потенциални примери:

• Платформи за електронна търговия: Платформа за електронна търговия може да използва Module Federation, за да отдели различни секции от уебсайта, като каталог на продукти, количка за пазаруване, процес на плащане и управление на потребителски акаунти, в отделни micro-frontends. Това позволява на различните екипи да работят върху тези секции независимо и да внедряват актуализации, без да засягат останалата част от платформата. Например, екип в *Германия* може да се фокусира върху каталога на продукти, докато екип в *Индия* управлява количката за пазаруване.
• Приложения за финансови услуги: Приложение за финансови услуги може да използва Module Federation, за да изолира чувствителни функции, като платформи за търговия и управление на акаунти, в отделни micro-frontends. Това подобрява сигурността и позволява независим одит на тези критични компоненти. Представете си екип в *Лондон*, специализиран в функциите на платформата за търговия, и друг екип в *Ню Йорк*, който се занимава с управление на акаунти.
• Системи за управление на съдържание (CMS): CMS може да използва Module Federation, за да позволи на разработчиците да създават и внедряват персонализирани модули като micro-frontends. Това дава възможност за по-голяма гъвкавост и персонализиране за потребителите на CMS. Екип в *Япония* може да създаде специализиран модул за галерия с изображения, докато екип в *Бразилия* създава усъвършенстван текстов редактор.
• Здравни приложения: Здравно приложение може да използва Module Federation за интегриране на различни системи, като електронни здравни досиета (EHR), портали за пациенти и системи за фактуриране, като отделни micro-frontends. Това подобрява оперативната съвместимост и позволява по-лесно интегриране на нови системи. Например, екип в *Канада* може да интегрира нов модул за телездравеопазване, докато екип в *Австралия* се фокусира върху подобряване на работата с портала за пациенти.

Заключение

Module Federation предоставя мощен и гъвкав подход за внедряване на micro-frontends. Като позволява на приложенията динамично да зареждат код един от друг по време на изпълнение, тя дава възможност за създаване на наистина независими и компонуеми frontend архитектури. Въпреки че изисква внимателно планиране и внедряване, ползите от повишена мащабируемост, по-бързи цикли на разработка и по-голяма екипна автономия го правят убедителен избор за големи и сложни уеб приложения. Тъй като пейзажът на уеб разработката продължава да се развива, Module Federation е настроена да играе все по-важна роля във формирането на бъдещето на frontend архитектурата.

Като разберете концепциите и най-добрите практики, описани в тази статия, можете да използвате Module Federation, за да създадете скалируеми, поддържаеми и иновативни frontend приложения, които отговарят на изискванията на днешния забързан дигитален свят.